Passenger protection device

ABSTRACT

A device for vehicle occupant protection. A processor connectable to at least two sensors may execute a deployment algorithm, and, in response to a failure of at least one of the sensors, may alter a sequence of execution of the deployment algorithm according to a point in time of the failure.

FIELD OF THE INVENTION

The present invention is directed to a device for vehicle occupantprotection.

BACKGROUND INFORMATION

A device for vehicle occupant protection may include sensors. Forexample, restraint systems having distributed sensors for frontal crashdetection are recently being used in greater numbers. In order to obtainmore information about the crash severity very early, sensors areinstalled in the actual crash zone. The side crash detection systemneeds such external sensors in the crash zone or in its proximity toactually be able to detect a side impact quickly enough. The trend inlarger vehicles is to install more than one sensor per side. Thesesensors may fail. Failure of even one sensor may cause a total failureof the device.

An aspect of the present invention is to prevent a total failure of adevice in the event of failure of an individual sensor or even aplurality of sensors.

SUMMARY

In an example embodiment of the present invention, the failure of onesensor of a device for vehicle occupant protection may be taken intoaccount in each phase of the deployment algorithm. This may prevent atotal failure of the restraint system in the event of failure of anindividual sensor or even a plurality of several sensors. A fallbackstrategy, adapted to each phase of the deployment algorithm, may be usedfor this purpose.

In one example embodiment, due to the greater complexity of currentrestraint systems, i.e., more sensors for the same task or function, inthe event that one sensor fails, the overall functionality may remainintact with only negligible adverse effects on performance. Differentapproaches for the different phases of the algorithm may be used here.

In one example embodiment, in the event that one sensor fails when thedevice is switched on, either the device may be switched off again, or acorresponding flag may be set in a memory for influencing the thresholdvalue computation for the deployment algorithm. It may be therebyestablished from the outset that this failure must be taken into accountin the deployment algorithm.

In one example embodiment, in the event that one sensor fails during thethreshold value computation, the signal of the failed sensor may bemaintained via a constant. Alternatively, the sensitivity of thedeployment algorithm may be altered, e.g., by lowering deploymentthresholds.

In one example embodiment, in the event that at least one sensor failsprior to determining the plausibility, a processor may determine theplausibility in an alternative manner via an additional sensor.

Exemplary embodiments of the present invention are explained in greaterdetail in the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that illustrates the components of the deviceaccording to an example embodiment of the present invention.

FIG. 2 is a flow chart that illustrates a procedure according to anexample embodiment of the present invention.

DETAILED DESCRIPTION

In an embodiment of the present invention, a device for vehicle occupantprotection may have a general response sequence in the event of sensorfailures. The point in time of the sensor failure may be considered. Thealgorithm for computing the deployment of a restraint system may havedifferent phases. A crash event may be anticipated in a first phase orthe normal operation, also referred to as the reset state. The signalsmay be greater in a second phase of the threshold value computation thanin normal driving situations, and the deployment algorithm may computethe deployment conditions from the signals. A comparison between thedeployment conditions and the sensor signals may be executed in thedeployment decision phase. In order to achieve greater reliability forthe deployment of a restraint system, a plausibility check of thedeployment condition may be executed in the plausibility phase usinginformation from another sensor. An adapted strategy regarding thefailure of at least one sensor may arise for each phase of thisdeployment algorithm. The device may be generally valid for restraintsystems. The same demands may thus be made for many particular systemconfigurations.

Compared to earlier systems, modern systems have greater complexity withregard to the plurality of sensors for the same task or function. Thisresults in a certain redundancy. In an example embodiment, thisredundancy may be utilized using a suitable failure strategy.

FIG. 1 shows a block diagram of the device according to an exampleembodiment of the present invention. The device may have a control unit1 and external sensors 5 and 6. Such external sensor systems may be ableto transmit pure sensor signals or pre-processed sensor signals,computed algorithm variables (thresholds, plausibilities), or deploymentdecisions.

These sensors 5 and 6 may be, for example, acceleration sensors, yawrate sensors, temperature sensors, or pressure sensors. Otherdeformation sensors may be also possible. Sensors 5 and 6 may beconnected to an interface module 4 that may be situated in control unit1. In one example embodiment, unidirectional connections from sensors 5and 6 to interface module 4 may be provided. In an alternative exampleembodiment, a bidirectional data transfer may be provided betweeninterface module 4 and sensors 5 and 6. The unidirectional orbidirectional connections may be implemented by a bus connection betweeninterface module 4 and sensors 5 and 6. Just one sensor, or three andmore sensors may be connected to one interface module 4.

Interface module 4 may be designed as a receiver module that may receivethe signals from sensors 5 and 6 and may transmit them to a processor 2in control unit 1. Processor 2 may be configured as a microcontroller,as a microprocessor, or even as a hardware module having a specifiedlogic. Processor 2 may analyze the sensor signals from sensors 5 and 6.In addition, another sensor 7 in control unit 1 may be connected toprocessor 2. This sensor 7 may be used as a plausibility sensor forsensing a side impact, for example. In one example embodiment, sensor 7may be designed as an acceleration sensor or as a yaw rate sensor. In anexample embodiment, more than one sensor may be provided in control unit1, e.g., sensors having an angular sensitivity axis to one another. Forensuring its function, processor 2 may be connected to a memory 3 via adata input/output.

FIG. 2 is a flow chart that illustrates the procedure of the deviceaccording to an example embodiment of the present invention, e.g., whichruns on processor 2. In an example embodiment, the device according tothe present invention may be switched on in step 10. A normal operation,during which a crash event is anticipated, may be provided in subsequentstep 11 referred to as RESET. If a failure of a sensor is determined inthis phase of the deployment algorithm, e.g., the absence of the sensorsignal, then the system may jump to step 12 in which it may be checkedwhether a fallback position exists. If this is not the case, then thesystem may jump to step 13 and the device according to the presentinvention may be switched off. If, however, a fallback condition isprovided for the failure at this point in time, then a flag may be setin step 14, e.g., indicating the failure of a particular sensor. Thismay then be taken into account during computation of the deploymentcondition.

After step 14, the system may jump to step 15 which may be additionallyreached by step 11 if there is no sensor failure. If starting conditionshave been detected in step 15, for example by exceeding a noisethreshold, the deployment algorithm may be started. The sensor signalsmay be taken into account here. If the noise threshold in step 15 wasnot exceeded, then the system may jump back to step 11. However, if thenoise threshold was exceeded and the algorithm is started, then thesystem may move to step 16 in which the deployment conditions for thedeployment of the restraining mechanism may be computed. If a sensorfails in this phase, the system may jump to step 19 in which it may bechecked whether a fallback strategy exists for this phase. If this isnot the case, then the device according to the present invention may beswitched off in step 20. Otherwise, the system may jump to step 21 inwhich the fallback strategy for this phase of the deployment algorithmmay be used. In one example embodiment, maintaining the signal of thefailed sensor via a constant may constitute a fallback strategy. In analternative embodiment, increasing the sensitivity of the deploymentalgorithm, e.g., by lowering the deployment thresholds, may constitutethe fallback strategy. After applying the fallback strategy, the systemmay jump to step 17 in which the deployment decision may be made.

Subsequent to a deployment decision in step 17, the system may jump tostep 18 for determining the plausibility of the deployment decision. If,however, a sensor failure was determined prior to computing theplausibility, e.g., failure of the sensor needed for the plausibilitycheck, then the system may jump to step 22. In step 22 it may be checkedwhether a plausibility flag has already been set in memory 3 byprocessor 2. If this is the case, then the failure of the sensor isirrelevant and the system may jump to step 23 in which restrainingmechanism 30 may be deployed. This deployment may take place adaptively.However, if it is determined in step 22 that the plausibility was notyet established, then the system may jump to step 24 in which it may bechecked whether a fallback strategy exists for the plausibility phase.If this is not the case, then the device may be switched off in step 25.If, however, a fallback strategy does exist for the plausibility phase,then it may be used in step 26. The plausibility check may be executedhere via a signal of another sensor, for example. This may be possiblewhen there is sufficient redundancy of sensors. Subsequently, the systemmay jump to method 23 where restraining mechanism 30 may be deployed.

1-6. (canceled)
 7. A device for vehicle occupant protection, comprising:a processor to execute a deployment algorithm; and at least two sensorsto detect an impact, wherein the at least two sensors are connectable tothe processor, and wherein, in response to a failure of at least one ofthe at least two sensors, the processor is to alter a sequence ofexecution of the deployment algorithm according to a point in time ofthe failure.
 8. The device according to claim 7, wherein, if the atleast one sensor fails when the device is switched on, the processorswitches the device off.
 9. The device according to claim 7, furthercomprising: a memory, wherein, if the at least one sensor fails when thedevice is switched on, the processor sets a flag in the memory, and athreshold value of the deployment algorithm is computed according to theflag.
 10. The device according to claim 7, wherein, if the at least onesensor fails during a threshold value computation of the deploymentalgorithm, the processor maintains a signal of the at least one sensor.11. The device according to claim 7, wherein, if the at least one sensorfails during a threshold value computation of the deployment algorithm,the processor is to alter a sensitivity of the deployment algorithm. 12.The device according to claim 7, wherein, if the at least one sensorfails prior to a determination of a plausibility for a deploymentcondition, the processor determines the plausibility via another of theat least two sensors.